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(54) Buffer management for mobile internet protocol 



(57) Disclosed is a buffer management method for a 
mobile node in a mobile IP telecommunication network. 
The buffer management method supports a handoff of 
the mobile node from a first agent of a first network to a 
second agent of a second network. The method begins 
upon initiation of the handoff. A first message is sent to 
the first agent requesting the first agent to buffer any 
packets being sent to the mobile node. While the buffer- 
ing is being performed, the handoff may be completed 
to the second agent Once the handoff is complete, a 
second message can be sent to the first agent request- 
ing the first agent to forward the buffered packets to the 
second agent. 
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Description 

[0001] This invention relates generally to manage- 
ment techniques for a wireless communications net- 
work and, more particularly, to a system and method for 5 
facilitating the seamless transfer of data to a mobile 
node as the mobile node roams in a mobile internet pro- 
tocol network. 

[0002] There are many emerging trends in the com- 
munications world, including the increase in mobile net- 10 
work technology and the rise in packet data networks. 
There are many types of mobile network technologies, 
including the global system for mobile communication 
("GSM"), code division multiple access ("CDMA"), time 
division multiple access ("TDMA"), and advanced 15 
mobile phone service ("AMPS"). Likewise, there are 
many types of packet data technologies, such as asyn- 
chronous transfer mechanism ("ATM") and internet pro- 
tocol (IP"). Packet data technologies send packets of 
data, or datagrams, in which sections of a message are 20 
transmitted in scattered order and then re-ordered at a 
receiving node. 

[0003] Mobile IP is an emerging "layer 3" type pro- 
tocol that allows a mobile node to establish a wireless 
connection to an IP network. Mobile IP essentially has 25 
three major subsystems. A first subsystem is a discov- 
ery mechanism that provides mobile nodes with new 
attachment points (new IP addresses) as they move 
within the IP network. A second subsystem allows the 
mobile node to register with its "home network" when it 30 
learns its new IP address. A home network is a network, 
possibly virtual, that has a network prefix matching that 
of the mobile node's "home address." A home address . 
is an IP address that is assigned for an extended period 
of time to the mobile node. It remains unchanged 35 
regardless of where the mobile node is attached. Stand- 
ard IP routing mechanisms will deliver packets destined 
to a mobile node's home address to the mobile node's 
home network. 

[0004] A third subsystem allows data to be directed 40 
to the mobile node when it is away from its home net- 
work by using the registered IP address. For the sake of 
reference, mobile IP is discussed in greater detail in the 
book Charles E. Perkins, MOBILE IP: DESIGN PRINCI- 
PLES AND PRACTICES (Computer & Engineering 45 
Publishing Group ISBN: 0-201-63469-4, 1998). 
In each of these systems, packets of information are 
often lost to a mobile node during handoff. What is 
needed is a system and method to reduce the number 
of lost packets when a mobile node hands-off from one so 
agent to another. 

[0005] The present invention provides a buffer man- 
agement method for a mobile node in a telecommunica- 
tion network. In one embodiment, the method supports 
a handoff of the mobile node from a first agent of a first 55 
network to a second agent of a second network. The 
method begins upon initiation of the handoff. A first 
message is sent to the first agent requesting the first 



agent to buffer any packets being sent to the mobile 
node. While the buffering is being performed, the hand- 
off may be completed to the second agent. Once the 
handoff is complete, a second message can be sent to 
the first agent requesting the first agent to forward the 
buffered packets to the second agent. 
[0006] A technical advance is achieved because 
the packets of information are buffered as a mobile 
node changes its network point of attachment, thereby 
reducing the possibility of lost data packets. 
[0007] Another technical advance is achieved by 
reducing an overall amount of buffering being per- 
formed by either agent. 

[0008] Exemplary embodiments of the present 
invention will now be described with reference to the 
accompanying drawings. 

Fig. 1 is a simplified description of several typical 
wireless networks and agents in which one or more 
embodiments of the present invention may be 
employed. 

Figs. 2-4 are flow charts for messages used to facil- 
itate a handoff of a mobile node from one agent to 
another. 

Figs. 5-9 are exemplary message structures, such 
as can be used in the flow charts of. Figs. 2-4. 

[0009] The present disclosure relates to buffer man- 
agement, such as can be used for mobile internet proto- 
col. It is understood, however, that the following 
disclosure provides many different embodiments, or 
examples, for implementing different features of the 
invention. Specific examples of components, mes- 
sages, sequences and arrangements are described 
below to simplify the present disclosure. These are, of 
course, merely examples and are not intended to limit 
the invention from that described in the claims. 
[0010] The following discussion is divided into 
seven different sections. The first section describes 
exemplary networks that may benefit from the present 
invention. The second section describes basic handoff 
scenarios for a mobile node in the exemplary networks. 
The third section describes messages and extensions 
for use in the handoff scenarios. The fourth and fifth 
sections describe unique considerations for the mobile 
node and a foreign agent, respectively. The sixth sec- 
tion describes buffer management for performing the 
handoff scenarios. Finally, the seventh section provides 
a conclusion. 

Exemplary Networks 

[0011] Referring now to Fig. 1 of the drawings, ref- 
erence numerals 10, 12, and 14 refer, in general, to sim- 
plified conventional mobile IP packet networks. The 
networks 10, 12, 14 allow a mobile node (MN) 16 to 
wirelessly communicate with a correspondence node 
18, which may be wired or wirelessly connected to the 
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networks. The MN 16 includes hardware components 
like a conventional wireless device, including a proces- 
sor, memory, and an interface, for wirelessly connecting 
to another node. The network 14 is, in the present 
example, the home network for the MN 16, and main- 
tains current location information for the MN 16 and 
delivers packets to the MN 16 when it is away. The MN 
16 includes the necessary components to establish a 
wireless connection to the networks 14 through a home 
agent (HA) 14a. The HA 14a is a node of the network 
14, and includes a conventional amount of processing, 
memory, and switching capacity. 
[0012] When away from its home network, the HA 
14 provides a "care-of address" for the MN 16. A care- 
of address is a termination point of a tunnel for packets 
forwarded to the MN 16 while it is away from home. 
There are two different types of care-of address: a for- 
eign agent care-of-address is an address of a foreign 
agent with which the MN 16 is registered, and a collo- 
cated care-of address is an externally obtained local 
address associated with one of its own network inter- 
faces. When the MN 16 is away from home, it registers 
its care-of address with its HA 14. The MN 16 uses its 
home address as the source address of all IP packets 
that it sends, except where otherwise required. 
[0013] The. MN 16 may roam by establishing wire- 
less (or wireline) connections with various foreign 
agents (FAs). A foreign agent is a router node in a "vis- 
ited" foreign network which cooperates with the home 
agent to complete the delivery of packets to the mobile 
node while it is away from home. Each FA includes a 
conventional amount of processing, memory, and 
switching capacity. A visited foreign network is a net- 
work other than a mobile node's home network, to 
which the mobile node is currently connected. Each for- 
eign agent maintains a visitor list of all the visiting 
mobile nodes. 

For the sake of example, FAs 10a, 12a of networks 10, 
12, respectively, are illustrated. The mobile node may 
roam to a location "a" and establish a wireless connec- 
tion with foreign agent 10a in network 10, and then may 
roam to a location "b n and establish a wireless connec- 
tion with foreign agent 12a in network 12. 
[0014] When the MN 16 is roaming (for instance, at 
position a), packets sent to the mobile node's home 
address are intercepted by the home agent 14a ( tun- 
neled to the care-of address, received at the tunnel end- 
point (FA 10a), and finally delivered to the mobile node. 
In the reverse direction, packets sent by the MN 16 are 
generally delivered to their destination using standard 
IP routing mechanisms, not necessarily passing 
through the home agent 14a. 

[0015] Mobile IP has a process called "IP security." 
IP security is a tunneling security context between a pair 
of nodes. For example, IP security may use a security 
parameters index for identifying a security context 
between a pair of nodes among the contexts available in 
the mobility security association. 
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[0016] Security and smooth handoff with minimal 
data loss and delay are desirable goals of any mobile 
network. Route optimization techniques attempt to 
solve some of the issues related to smooth handoff, but 

5 difficulties stilt arise. Additionally, it may be necessary 
for the MN to authenticate the new FA before allowing it 
(the new FA) to receive data from the previous FA. In 
such cases, the new FA is authenticated by the MN's 
home agent (HA) during the handoff. 

10 [0017] For example, consider a communicating 
node (CN) 18 connected to the network 14. The CN 18 
may be a computer server that is sending packets to the 
MN 16. Traditionally, when the MN 16 moves from point 
a to point b, FA 10a immediately begins to forward pack- 

15 ets to FA 12a. This is a problem because handoff to the 
FA 12a may not be completed. This results in a breach 
of security because the FA 12a has not been authenti- 
cated. This also may result in a loss of one or more 
packets. To recover from the loss of one or more pack- 

20 ets, the CN 18 must resend these packets, thereby 
degrading the general performance of the overall net- 
work. 

[0018] Instead, the present invention decreases the 
window of data loss and delay during handoff. In partic- 
25 ular, a new buffer management method minimizes the 
. potential loss of data while the MN changes its network 
point of attachment. In addition, the buffer management 
method provides a way for the MN to verify the new FA 
during the handoff, if and when that is needed. 

30 

Basic Scenarios 

[0019] In mobile IP, there are three basic types of 
handoff. The first type is called Mobile Assisted Handoff 

35 (MAH). In MAH, the Mobile Node (MN) discovers that it 
needs to move to a new FA and initiates the handoff. 
The second type is called System Assisted Handoff 
(SAH). In SAH, the new FA initiates the handoff after the 
MN sends a Registration Request. The third type of 

40 handoff is called Previous FA Notification Extension 
Handoff (PFANEH). In PFANEH, the MN starts the 
handoff process after entering the new FA. It is 
assumed that there is a security association between 
new FA and previous FA while performing PFANEH. 

45 

1. Mobile Assisted Handoff 

[0020] Fig. 2 shows the message flow between the 
MN and the FA during a Mobile Assisted Handoff. Refer- 

50 ring also to Fig. 1 for example, the MN 16 is roaming 
from a position A to a position B, and is being handed off 
from FA 10a ("Previous FA") to FA 12a ("New FA"). The 
following steps are performed in Fig. 2. These steps uti- 
lize certain messages which are described in greater 

55 detail below, with respect to Figs. 5-9. 

(a) A Buffer Control Request message is sent to the 
previous FA as soon as the MN discovers that it 
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needs to move to the new FA. The previous FA 
starts to buffer data that are destined for the MN. 

(b) In some cases, the previous FA returns a Buffer 
Control Response message to the MN. 

(c) The MN moves to the new FA and sends a Reg- 
istration Request message. 

(d) The new FA registers the MN and returns a suc- 
cessful Registration Reply message. 

(e) The MN sends a Buffer Control Request mes- 
sage to the previous FA requesting it to forward the 
buffered data. 

(f) In some cases, the previous FA returns a Buffer 
Control Response message to the MN. 

[0021] During MAH, if the MN loses its direct com- 
munication (over the air) with the previous FA and fails 
to receive an expected Buffer Control Response mes- 
sage, the MN then should, in the present embodiment, 
change to either SAH or PFANEH mode (as described 
below) upon entering the new FA. 

2. System Assisted Handoff 

[0022] Fig. 3 shows the message flow between the 
MN and the FA during a System Assisted Handoff. 
Referring also to Fig. 1 for example, the MN 16 is roam- 
ing from a position A to a position B, and is being 
handed off from FA 10a ("Previous FA") to FA 12a ("New 
FA"). The following steps are performed in Fig. 3. These 
steps utilize certain messages which are described in 
greater detail below, with respect to Figs. 5-9. 

(a) The MN moves to the new FA and sends a Reg- 
istration Request message with a Buffer Control 
Request extension. 

(b) The new FA sends a Binding Update message 
with a Buffer Control Request message to the MN. 
At this point, the new FA should start to buffer data 
destined for the MN. 

(c) In some cases, the previous FA sends a Binding 
Acknowledgment message with a Buffer Control 
Response extension to the new FA. 

(d) In some cases, the new FA forwards the Binding 
Acknowledgment message with the Buffer Control 
Response extension to the MN. 

(e) The new FA registers the MN and returns a suc- 
cessful Registration Reply message. 

(f) The MN sends a Buffer Control Request mes- 
sage to the previous FA requesting it to forward the 
buffered data. 

(g) In some cases, the previous FA returns a Buffer 
Control Response message to the MN. 

[0023] During SAH, if a MN receives a successful 
Registration Reply message before an expected Bind- 
ing Acknowledgment message from the previous FA, 
the MN should, in the present embodiment, wait for the 
Binding Acknowledgment message prior to executing 



step (f). 

3. Previous FA Notification Extension Handoff 

5 [0024] Fig. 4 shows the message flow between the 
MN and the FA during a handoff that uses Previous For- 
eign Agent Notification extension. Referring also to Fig. 
1 for example, the MN 16 is roaming from a position A to 
a position B, and is being handed off from FA 10a ("Pre- 

w vious FA") to FA 12a ("New FA"). The following steps are 
performed in Fig. 4. These steps utilize certain mes- 
sages which are described in greater detail below, with 
respect to Figs. 5-9. 

15 (a) The MN sends a Registration Request message 
to the FA (e.g., the previous FA) at the initial regis- 
tration, with a Buffer Control Request extension. 
The FA allocates a buffer for the MN. 

(b) The FA (e.g., the previous FA) sends a Registra- 
20 tion Reply message, which may include a Buffer 

Control Response extension, to the MN. 

(c) The MN moves to a new location and sends a 
Registration Request message to the new FA with 
a Previous FA Notification extension. It also adds 

25 two Buffer Control Request extensions: one for the 
new FA (with B = 1) to start buffering for the MN, 
and the other for the previous FA (with F = 1) so that 
it can forward the data to the MN. Both of these 
extensions may include other relevant information 

30 (IP Filter Extension, for example) pertaining to 
buffer management. 

(d) The previous FA creates a buffer for the MN and 
continues to buffer its data. This buffer is created 
according to the specification provided in the Buffer 

35 Control Request extension that was sent with the B 
bit set (B = 1). The new FA also sends a Binding 
Update to the previous FA with the Previous FA 
Notification extension as well as the Buffer Control 
Request extension that was sent with the F bit set 

40 (F = 1). The previous FA starts to forward data to 
the MN as soon as it receives the Binding Update 
message (according to the specifications provided 
in the Buffer Control Request extension). 

(e) The new FA registers the MN and returns a suc- 
45 cessful Registration Reply message, and may 

include a Buffer Control Response extension. 

Messages and Extensions 

so [0025] In this section, a set of messages and exten- 
sions that are used in buffer allocation and management 
will be further described. 

1. Buffer Control Request Message 

55 

[0026] This message is sent from the MN to the FA 
to allocate and manage data buffers for the MN. This 
message may be an individual message or may be 
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added as an extension to Registration Request and 
Binding Update messages. This may be sent by the 
mobile node during registration (as an extension to the 
Registration Request) or it may be sent by the MN prior 
to (or as soon as) the discovery of handoff. This mes- 
sage is always sent to the FA. This message should, in 
the present embodiment, be implemented by both the 
FA and the MN for all of the scenarios (MAH, SAH and 
PFANEH) mentioned above. 

[0027] The exemplary structure of this message is 
shown in Fig. 5. The flags are discussed below: 

Type. This is for various type indications. 

A. This flag indicates if the FA should allocate a 
buffer for the MN. 

A = 0, allocate a buffer of default size (as 
decided by the FA). 

A = 1, allocate a buffer of size defined in the 
Buffer Size extension. 

B. This flag indicates if the FA should start buffering 
data that is destined for the MN. This should not, in 
the present embodiment, be set simultaneously 
with the F bit. 

B = 0, do not buffer data. 
B = 1 1 start to buffer data. 

D. This flag indicates if the FA should stop buffering, 
deliver all the packets buffered so far, and then 
finally delete the buffer previously allocated for the 
MN. 

D = 0, do not stop buffering or delete the MN's 
buffer. 

D = 1 , stop, deliver all packets buffered so far to 
the MN and then delete the MN's buffer. 

F. This flag indicates if the FA should forward data 
stored in the buffer to the MN. This should not, in 
the present embodiment, be set simultaneously 
with either B or K flag. 

F = 0, do not forward the data. 
F = 1 , forward the data. 

I. This flag indicates if the Buffer Control Request 
message has the identification field. 

I = 0, identification field is not included. 
1 = 1, identification field is included. 

K. This flag indicates if the FA should send an 
acknowledgment (Buffer Control Response) mes- 
sage to the MN. 

K = 0, FA should not send any acknowledg- 



ment message. 

K = 1, FA should send an acknowledgment 
message. Appropriate extensions should, in 
the present embodiment, be added if the FA 
5 can not allocate the buffer resources requested 

by the MN. 

L. This flag indicates the type of the buffer. 

w L = 0, a fixed length buffer. 

L = 1 , a variable length buffer. 

MN IP address. The MN's home IP address. 
Identification. An optional 64-bit number, con- 
15 structed by the MN. It is used for identifying the 
response to Buffer Control Request message. It is 
also used as protection a from replay attacks. It's 
included in the message if the I flag is set (1 = 1). 

20 2. Buffer Control Response Message 

[0028] This message is sent from the FA to the MN 
in response to a Buffer Control Request message. This 
message may be an individual message or may be 
25 added as an extension to Registration Reply and Bind- 
ing Acknowledgment messages. Some embodiments of 
the FA and the MN may not use this message. 
[0029] The exemplary structure of this message is 
shown in Fig. 6. The flags are discussed below. 

30 

Type. This is for various type indications. 
A. This flag indicates if the buffer specifications pro- 
vided by the MN (in the Buffer Control Request 
message) are rejected, accepted or partially 

35 accepted by the FA. The partial acceptance of the 
buffer specifications may occur if the FA's system 
resource can not accommodate all the require- 
ments requested by the MN. If this option is 
selected, the available buffer resources of the FA 

40 should, in the present embodiment, be sent by the 
appropriate extensions (e.g. Buffer Size extension 
or a Buffer Lease Time extension) to the MN. 

A = 0, the FA accepts the buffer specifications. 
45 A = 1 , the FA partially accepts the buffer speci- 

fications. New specifications are sent with the 
appropriate extensions. 

A = 2, the FA rejects the buffer specifications. 
Sender IP address. The IP address of the FA. 

50 

Identification. A 64-bit number, constructed by the 
MNandsentina Buffer Control Request or Regis- 
tration Request message. It is used for identifying 
the response to a Buffer Control Request or Regis- 
55 tration Request message. It is also used as a pro- 
tection from replay attacks. 
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3. Buffer Size Extension 

[0030] This extension defines the size of the buffer 
that should be allocated for the mobile node by the 
agent or the size of the buffer that is offered by the agent 
to the mobile node. 

[0031] The exemplary structure of this message is 
shown in Fig. 7. the flags are discussed below. 

Type. This is for various type indications. 

Length. The length of this extension in number of 

bytes. 

Size. The size of the buffer required by the MN or 
the size of the buffer offered by the FA to the MN. 
The size is of 1K increments. 

4. Buffer Lease Time Extension 

[0032] This extension defines a lease time of the 
buffer that should be allocated to the mobile node by the 
mobile agent or the lease time of the buffer that is 
offered by mobile agent to the mobile node. 
[0033] The exemplary structure of this message is 
shown in Fig. 8. The flags are discussed below. 

Type. This is for various type indications. 

Length. The length of this extension in number of 

bytes. 

Lease Time. The lease time of the buffer required 
by the mobile node or the lease time of the buffer 
offered by the mobile agent to the mobile node. The 
lease time is counted in seconds and the value 
0XFFFFFFFF is a reserved number to indicate infi- 
nite time. 

5. IP Filter Extension 

[0034] This extension is used to filter (e.g., discard) 
the data packets destined for the MN based on their 
source IP addresses and the packet identification field. 
[0035] The exemplary structure of this message is 
shown in Fig. 9. The flags are discussed below. 

Type. This is for various type indications. 

Length. The length of this extension in number of 

bytes. 

IP count. The number of IP addresses listed in this 
extension. 

C. This flag indicates if the FA should buffer the 
packets that have the same or different source IP 
addresses listed in this extension. This flag should 
be checked only for those IP addresses that do not 
include any IP IDs in this extension. 

C = 0, buffer or forward packets that have the 
same IP addresses as listed in this extension. 
C = 1, buffer or forward packets that do not 
have the same IP addresses as listed in this 



extension. 

IP address(s). The IP address(s) included in this 
extension. 

5 ID count. The number of IP identifications included 
per IP address. 

IP index. This field uniquely identifies an IP address 
from the list of the IP addresses included in this 
extension. The value of this field corresponds to the 

w sequence number (starting at zero) in which a par- 
ticular IP address is listed. For example, if this field 
contains zero (0), then it identifies the first IP 
address listed in this extension. Hence, all IP IDs 
corresponding to that IP address are included in a 

15 tuple: 

«P Index = 0, ID Count = n, IP ID1 ... IP IDn} 
where n is the number of IP IDs for this particular IP 
address. Similarly, if an IP Index field contains two 
(2), then all the IP IDs listed following the tuple: 
20 iP Index = 2, ID Count = n, IP ID1 ... IP IDn> 

correspond to the third IP address listed in this^ 
extension. 

If a particular IP address does not have any IP , 
IDs, then the sequence number of that IP address 

25 should not, in the present embodiment, be present 
in the list of IP Index fields. For example, if the sec- 
ond IP Address listed does not have any IP IDs, 
then any IP Index with a value of one (1) should not, 
in the present embodiment, be present in this 

30 extension. If any IP address listed in the this exten- 
sion is not identified by the IP Index field, then all of 
those IP addresses should, in the present embodi- 
ment, be completely filtered (based on the C flag). 
IP ID. The IP identification(s) included for the IP 

35 address identified by an IP index. If the very last IP 
ID happens to be in the lower 16 bytes, then the 
upper 16 bytes should, in the present embodiment, 
be padded. 

40 6. Authentication Extension 

[0036] This extension is used to authenticate Buffer 
Control Request and Buffer Control Response mes- 
sages, only if they are sent independently (that is, they 
45 are not sent as extensions to a Registration Request or 
Binding Update message). 

[0037] This extension has the same format and 
default algorithm support requirements as the 
Authentication extensions (MN-FA, MN-HA, HA-FA) 

50 defined in the base Mobile IP. However, it should, in the 
present embodiment, have its own type. 
[0038] An authenticator value may also be included. 
The authenticator value can be computed from the 
stream of bytes including the shared secret key, pay- 

55 load, prior extensions, and the type and length of this 
extension. 
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Mobile Node Considerations 

[0039] The MN may send the Buffer Control 
Request message to the FA as a separate message or 
as an extension to a Registration Request message. 5 
The MN may receive the Buffer Control Response from 
the FA as a separate message or as an extension to the 
Registration Reply message. 

[0040] The MN should, in the present embodiment, 
explicitly notify the FA (e.g., via the IP Filter extension) if w 
the buffering needs to be discriminated based on the 
source IP address and/or the IP Identification field. 
[0041] The MN may add two Buffer Control 
Request extensions to a single Registration Request 
message while sending it to a FA. This situation may 15 
occur when a MN needs to notify a new FA to allocate a 
buffer, and at the same time, the MN needs to notify the 
previous FA (e.g., via the new FA) to forward buffered 
data. The MN should, in the present embodiment, also 
include a Previous FA Notification extension to this Reg- 20 
istration Request message. In this case, the MN should 
set the B bit (B = 1) in the Buffer Control Request mes- 
sage that is destined for the new FA. The MN should 
also set the F bit (F = 1) in the Buffer Control Request 
message that is destined for the previous FA. 25 

Foreign Agent Considerations 

[0042] The FA may receive the Buffer Control 
Request from a MN as a separate message or as an 30 
extension to a Registration Request message. The FA 
may send a Buffer Control Request message to another 
FA as a separate message or as an extension to a Bind- 
ing Update message. 

[0043] The FA may send the Buffer Control 35 
Response to a MN as a separate message or as an 
extension to the Registration Reply message. 
[0044] The FA may receive two Buffer Control 
extensions in a single Registration Request message 
from a MN. This Registration Request should, in the 40 
present embodiment, also include a Previous FA 
Notification extension. The FA should, in the present 
embodiment, allocate the buffer resources for the MN 
according to the specifications provided by the Buffer 
Control Request that has its B bit set (B = 1). The FA 45 
should, in the present embodiment, send the other 
Buffer Control Request that has its F bit set (F = 1) to 
the previous FA (as detailed in the Previous FA 
Notification extension) as an extension to the Binding 
Update message. so 
The FA, by default, should, in the present embodiment, 
buffer all the packets destined for the MN unless other- 
wise specified by the IP Filter extension. 
The FA should, in the present embodiment, follow the 
format of these messages as described herein. 55 



Buffer management 

1. Storing data 

[0045] The data stored in the buffer is managed 
according to the type of buffer mentioned in the T field of 
the System Change Request message. If the length of 
the buffer is fixed as mentioned in the L field of the 
Buffer Control Request message then the data will be 
stored in the buffer using a FIFO (First In First Out) pol- 
icy. If and when the buffer gets full, data at the front of 
the buffer (the oldest data) is discarded to make room 
for new data inserted at the end of the buffer. 
[0046] If the length of the buffer is variable and the 
buffer is full then the system will try to expand the size of 
the buffer to accommodate the new coming data. If the 
expansion is impossible then the data at the front of the 
buffer is discarded to make room for new data. The dis- 
carded data will be lost unless the F flag was set (F = 1 ) 
in the Buffer Control Request message. In that case, 
the data will be forwarded to the new FA. 

2. Buffer allocation 

[0047] One of the following cases occurs during 
buffer allocation when the MN sends Buffer Control 
Request message to the FA with a bit set to 1 (one): 

1. 

If no buffer is allocated for the MN then the allo- 
cation of buffer will be handled as follows: 
If the K is set to 0 (zero) and the MN includes 
the Buffer Size extension and/or Buffer Lease 
Time extension, then the buffer is allocated 
according to the size and the lease time men- 
tioned in these extensions. 
If, however, the FA is unable to accommodate 
the specifications (size, lease time etc.) 
Requested by the MN, the default values are 
then used to allocate the buffer. 
If either one or all of these extensions are not 
included then the FA's default values are used 
to allocate the buffer. 

If the K flag is set to 1 (one) and the MN's 
requested buffer specifications (included in the 
Buffer Size extension and/or Buffer Lease 
Time extension) can not be accommodated by 
the FA, then it (the FA) should, in the present 
embodiment, suggest its own buffer specifica- 
tions (size, lease time, etc.) To the MN through 
the Buffer Control Response message using 
the appropriate extensions. At the same time, 
the FA should, in the present embodiment, allo- 
cate those suggested buffer resources for the 
MN. 

If the new buffer specifications (size, lease 
time, etc.) Sent by the FA are not acceptable to 
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the MN, then the MN may send a new Buffer 
Control Request message to the FA with the 
new specifications. 

If the FA receives a Buffer Control Request 
message with both A and B flags set to 1 (one), 5 
the allocation of the buffer is done first followed 
by the start of buffering of all the appropriate 
packets that are destined for the MN. 
If the FA receives a Buffer Control Request 
message for a MN that has already allocated 10 
buffer, the FA then re-allocates the buffer 
according the most recent Buffer Control 
Request message. 



3. Forwarding Data 15 

[0048] Upon receiving a Buffer Control Request 
message with F = 1 and D = 1, the FA should, in the 
present embodiment, delete the buffer allocated to the 
MN after forwarding the entire buffer. Future packets 20 
received after this message are lost. 
[0049] Upon receiving a Buffer Control Request 
message with F = 1 and D = 0, the FA should, in the 
present embodiment, delete the buffer allocated to the 
MN after forwarding the entire buffer. Future packets 25 
received after this message are immediately (without 
being buffered) forward to the MN. The filtering rules (if 
any) specified while allocating the buffer should, in the 
present embodiment, be kept in place. The forwarding 
will continues until the lease time expires. 30 

4. Buffer Deletion 

[0050] The buffer will be implicitly deleted if the 
lease time expires. It will be explicitly deleted if the MN 35 
sends a Buffer Control Request message with the D 
flag set to 1 (one). 

[0051] Alternative embodiments of the invention 
may be implemented as computer program code 
encoded on a computer program product for use with a 40 
computer system. It is expected that such a computer 
program product may be distributed as a removable 
medium with accompanying printed or electronic docu- 
mentation (e.g. shrink-wrapped software), preloaded 
with a computer system or distributed from a server or 45 
electronic bulletin board over a network (e.g. the Inter- 
net or World Wide Web). A series of computer instruc- 
tions can therefore either be fixed on a tangible medium 
or fixed in a computer data signal embodied in a carrier 
wave that is transmittable to a computer system using so 
wireline or wireless transmission techniques. The 
removable (i.e. tangible) medium may be a computer 
readable media, such as a diskette, CD-ROM, DVD- 
ROM or RAM, fixed disk, magneto-optical disks, ROMs, 
flash memory or magnetic or optical cards. The series 55 
of computer instructions embodies all or part of the 
functionality previously described herein with respect to 
the system. 



[0052] Software embodiments of the invention may 
be implemented in any conventional computer program- 
ming language. For example, preferred embodiments 
may be implemented in a procedural programming lan- 
guage (e.g. "C") or an object oriented programming lan- 
guage (e.g. "C++"). 

[0053] Although the preferred operating method is 
realised by general or specific-purpose processor or 
logic circuits programmed with suitable machine-exe- 
cutable instructions, hardware components may possi- 
bly be used to implement certain features of the present 
invention. Of course, the present invention may be per- 
formed by a combination of hardware and software. 

Conclusion 

[0054] The present invention provides a unique sys- 
tem and method that manages packets and other types 
of data in handoff situations, such as those that occur in 
a mobile IP network. It is understood that the above dis- 
closure provides many different embodiments, or exam- 
ples, for implementing different features. Techniques 
and requirements that are only specific to certain 
embodiments should not be imported into other embod- 
iments. Also, specific examples of networks, compo- 
nents, and formats are described below to simplify the 
present disclosure. These are, of course, merely exam- 
ples and are not intended to limit the invention from that 
described in the claims. 

Claims 

1 . A method for supporting a handoff of a mobile node 
from a first agent of a first network to a second 
agent of a second network, the method comprising 
the steps of: 

upon initiation of the handoff, sending a first 
message to the first agent requesting the first 
agent to buffer any packets being sent to the 
mobile node; 

completing the handoff to the second agent; 
and 

sending a second message to the first agent 
requesting the first agent to forward the buff- 
ered packets to the second agent. 

2. The method of claim 1 , wherein the first message is 
part of a registration request protocol to the second 
agent. 

3. The method of claim 1 or 2, wherein the second 
message is also part of the registration request pro- 
tocol, occurring after the second agent has been 
authorized. 

4. The method of any preceding claim, wherein the 
first and second networks are mobile internet proto- 
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col networks. 

5. The method of any preceding claim, wherein the 
second agent is a foreign agent to the mobile node. 

6. The method of any preceding claim, wherein the 
mobile node sends the first message to the first 
agent. 

7. The method of any of claims 1 to 5, wherein the 
second agent sends the first message to the first 
agent. 

8. The method of any preceding claim, further com- 
prising: 

sending, by the mobile node, a buffer control 
request. 

9. The method of claim 8, further comprising: 

sending an indicator to the second agent that 
the mobile node has requested buffering. 

10. The method of any preceding claim, wherein the 
first message includes an indicator of a buffer size. 

11. The method of any preceding claim, further com- 
prising: 

discarding, by the first agent, predetermined 
packets when a maximum number of packets 
have been received. 

12. The method of any preceding claim, further com- 
prising: 

signaling the first agent to delete the buffered 
packets. 

13. The method of claim 12, further comprising: 

signaling forwarding any packets received after . 
the buffered packets are deleted. 

14. The method of any preceding claim, wherein the 
first message includes an indicator of a maximum 
length of time that buffering is needed. 

15. The method of any preceding claim, wherein the 
first message includes an indicator of authenticity 
for the buffering. 

16. The method of any preceding claim, wherein the 
first message includes an IP fitter to identify certain 
packets that do not need to be buffered. 

17. The method of any preceding claim, wherein the 



first agent is an old servicing node. 

18. A computer program element comprising computer 
program code means arranged to support imple- 

5 mentation of the steps of any preceding claim. 

19. The computer program element of claim 18, 
embodied on a computer readable medium. 

10 20. A system for supporting a handoff of a mobile node 
from a first agent of a first network to a second 
agent of a second network ,the system comprising: 

means for sending, upon initiation of the hand- 
15 off, a first message to the first agent requesting 

the first agent to buffer any packets being sent 
to the mobile node; 

means for completing the handoff to the sec- 
ond agent; and 
20 ' means for sending a second message to the 

first agent requesting the first agent to forward 
the buffered packets to the second agent. 

21. A modulated communication signal comprising a 
25 plurality of message portions arranged to support 
the first message and the second message of any 
of claims 1 to 17. 
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